Application Note HP Software Integration Sockets Connecting Foreign
Host Applications to HP Sockets using NCS

1.0     Introduction

The purpose of this document is to describe a design for using the
Network Computing System (NCS) to establish communication between
applications running within an HP Sockets domain and an application
running on a platform which is supporte d by NCS but not by HP Sockets.
This platform and the application which runs on it are referred to,
throughout this document, as a foreign host and a foreign ap plication.

This document will be primarily useful for technical people who would
like to know how to implement such a system. The reader is assumed to
have a technical understanding of both HP Sockets and NCS. For those
who need it, a brief background of NCS and HP Sockets is provided in
Appendix A.

The document begins with an overview of the connection followed by an
in-depth look at each part of the design. This should provide the
reader with a quick understanding of what is involved with building
such a system. Code for a sample implementation is available from HP
for anyone who would like it.


2.0     Overview of the NCS and HP Sockets Connection

NCS's interprocess communication capability can be used to connect a
foreign application to the HP Sockets domain. The client-server model
eminent in NCS's RPC mechanism provides a good solution for foreign
applications to gain access to the functionality of HP Sockets.

In this design, NCS will be used as the communication mechanism between
the foreign host and a machine within the HP Sockets domain (See Figure
1-1). More spec ifically, the foreign application adaptor, an NCS
client, will issue an HP Socke ts call. The execution of this call is
routed to a gateway server, an NCS server , which will then make the
actual HP Sockets call. The NCS server will contain one procedure for
each of the HP Sockets routines. The foreign application adap tor will
call NCS's remote procedure using the same name and passing the same pa
rameters as if it were the actual HP Sockets call. When the remote
procedure in the server executes, it will turn around and make the real
HP Sockets call, passing the values which were sent to it. After HP
Sockets returns, the return value is sent back to the foreign adaptor
as the return value for the remote procedure. This design allows the
foreign adaptor to have full control of the call into the HP Sockets
domain.

This design is a simple design in which the NCS server provides a
gateway connection for one foreign application at a time. This scheme
establishes a direct pip eline from the foreign application through a
gateway server and into the HP Sockets domain. The foreign application
adaptor can exist as a stand- alone process or it can be integrated
into the application just like an ordinary HP Sockets application
adaptor.



*** Object: Untitled


Figure 1-1


2.1  Flow of a typical call from a foreign application to an
application with in the HP Sockets domain

The following describes what happens in a typical call from the foreign
application adaptor through NCS to the gateway server and then into HP
Sockets.

1) The foreign application adaptor, an NCS client, makes a remote
procedure call (e.g. SpSendMsg_$NCS). This call could have been
initiated directly from the foreign application or indirectly from a
separate application adaptor process.

2) The remote procedure call (RPC) goes directly into the client stub
routine. This routine acts as if it were the remote procedure, but
instead it marshals the input parameters into an RPC packet.

3) The client stub calls an internal routine which transmits the RPC
packet over the network to the NCS server and then waits for a reply.

4) If the NCS handle is bound to a host, the RPC packet is sent
directly to that host. Once at the host, if the handle specifies a
well-known port, the request goes to that port. Otherwise, the request
goes to the Local Location Broker forwarding port. The LLB forwarding
mechanism will then forward the RPC to the appro priate NCS server. In
this case there is only one, the gateway server.

5) The RPC Runtime Library associated with the server receives the
packet and sends it to the appropriate server stub routine. This
routine unmarshals the input parameters from the request packet into
the data types expected by the server ( the data types specified in the
interface definition).

6) The server stub converts the data into the server's native
representation if it's different from the client's native
representation. For instance, a charact er parameter might be converted
from EBCDIC to ASCII.

7) The server stub then calls the correct remote procedure (e.g.
SpSendMsg_$NCS) .

8) Now execution is finally in the remote procedure. It is here that
the actual HP Sockets call is made (e.g. SpSendMsg).

9) HP Sockets receives the call from the gateway server and performs
the appropriate action.

2.2  Overview of Development Tasks

The following is an overview of what tasks need to be done in order to
implement a foreign host connection using NCS.

 * Configure the HP Sockets domain to include the gateway server as an
HP Sockets process.

 * Use the Network Interface Definition Language (NIDL) to define the
network interface between the foreign host and the gateway server.
After this is complete, run the NIDL file through the NIDL compiler to
produce the client and server stubs.

  * Create the gateway server initialization code that registers and
establishes communication with the NCS runtime environment.

 * Create the manager section of the gateway server which contains the
actual code for the remote procedures.

 * Create a foreign application adaptor as if it were an ordinary HP
Sockets adaptor. However, replace each HP Sockets call with the
corresponding remote procedure call. The name of each remote procedure
is identical to its HP Sockets counterpart except an extension (_$NCS)
is needed. This is necessary otherwise name conflictions will occur on
the gateway server code.


3.0     The Design of a Foreign Host Connection

The following section takes a closer look at each of the tasks a
developer must do to use NCS as a connection between a foreign host and
the HP Sockets domain.

3.1     HP Sockets Configuration

Configuring the HP Sockets domain to include the specification of the
gateway server requires the modification of at least two configuration
files (the Process Definition file, to add the gateway server process,
and the Network Definition file, to add the node that the gateway
server will run on). If the system requires HP Sockets to re-align
data, perform data manipulation, or transfer a file, then additional
information will be needed in the remaining files. For more infor
mation on configuring an HP Sockets domain see chapter 4 of the HP
Software Integration Sockets Programmers Manual.

3.2     NIDL Definition

The next task is to use NIDL to specify the network interface between
the foreign application adaptor and the gateway server. Since the goal
is to transparently connect up to the HP Sockets domain, the interface
for each remote procedure should be as close as possible to the
corresponding HP Sockets access routine. The name of each remote
procedure should be the same as the name of each HP Sockets routine.
However, in order to avoid name conflictions on the gateway server, the
name must be different. An extension (_$NCS) is used in the sample
implementat ion provided by HP. For example, figure 1-2 shows a section
of the sample NIDL code which defines the remote procedure for the
SpSendMsg call. Another thing to notice is that the handle is declared
as an implicit_handle and therefore not passed as a parameter to the
remote procedure. This allows the developer to define only the
parameters that are needed for the specific call being emulated. There
is one exception and that is if the message buffer for either
SpSendMsg_$NCS or SpReadQ_$NCS is declared as an open array. If an open
array is used then the size variable, for the last_is attribute, must
also be passed to the remote procedure.



*** Object: code1


Figure 1-2


By specifying the message buffer as an array of byte, the foreign
adaptor is able to send multiple data types with the same procedure
call (exactly what HP Sockets allows). However, NCS will not perform
any data conversion since it does not know what types are being passed.
This leaves the burden up to the developer to handle any data
conversion or alignment problems that might occur because of different
data representations between the foreign host and the gateway server.
For more information and a solution to this problem see Appendix B:
Advanced Topics.

3.3     Gateway Server Initialization

The server initialization code, which establishes communication with
the NCS run time environment, usually appears in the server's main
procedure. Typically this code starts off by processing the command
line arguments which would probably contain the name of the protocol
being used between the client and the server (for example ip or dds).
After converting the protocol name to its integer representation and
validating it, a socket address is created using the rpc_$use_family
call.

        rpc_$use_family(family, &sockaddr, &socklen, &status);

The server will then register the socket address with the location
broker so that the forwarding mechanism will know which socket the
server is listening on. The server must also register its manager but
with the RPC Runtime Library using t he rpc_$register_mgr call.

The initialization code for the server must then create a cleanup
handler that w ill be executed when a fault occurs. If a signal is
received by the process, the cleanup handler will unregister the server
with the location broker as well as the RPC Runtime Library, before
exiting. Now the server can call rpc_$listen in order to begin
listening for requests.


3.4     Manager Section

The manager is the section of the server which contains the actual code
for the remote procedures. The manager starts off by defining the entry
point vectors (E PV) through which the routines are called.

After this, a routine is implemented for each of the remote procedures
defined in the NIDL file. Most of the routines just call the HP Sockets
routine and then return the status back to the client. One exception is
the SpErrLog_$NCS routine . This routine is passed two parameters, a
message and an integer specifying the length of the message. Since it's
possible for NCS to convert the message from one character
representation to another, the message length should be recomputed
before the actual SpErrLog routine is called. Another exception is the
SpReadQ_ $NCS routine. If the buffer parameter is defined as an open
array, the size variable must be set to the length of the buffer before
returning to the client (See Figure 1-3).



*** Object: code2


Figure 1-3


If the buffer in SpSendMsg_$NCS or SpReadQ_$NCS is declared as the
actual type of data that it contains, its possible for NCS to perform
data conversion. Taking this into account, the IList[SpBUF_LEN]
parameter should be reset by the gateway server, before the actual call
to SpSendMsg is made. The SpReadQ_$NCS routine is not so lucky. Since
data conversion occurs on the way back from the gateway server, there
is no way to correctly set the value for the OList[SpBUF_LEN] param
eter. This is something that the developer should watch out for. See
Appendix B: Advanced Topics for more information on this topic.

3.5     Foreign Application Adaptor

The first thing that the foreign application adaptor must do is create
and bind a handle to the NCS server that will provide the gateway
service into the HP Sockets domain. The hostname for the NCS server
might be hard coded, passed in on the command line, or found from a
lookup request to the Global Location broker. After converting the name
of the address family into its integer representation, a socket address
can be created by using the socket_$from_name call.

socket_$from_name(family, server_hostname, hostname_length,
socket_$unspec_po rt, &sockaddr, &socklen,&status);

Now a handle can be allocated and bound to the socket address using the
rpc_$bin d call.

gateway_handle = rpc_$bind(&uuid_$nil, &sockaddr, socklen, &status);

The rest of the code can be developed as if it were an ordinary
application adaptor. There are only a couple of things that are
different. First of all, instead of using the actual HP Sockets call
the remote procedure is used (i.e. SpInit_$ NCS instead of SpInit).
Secondly, special precautions might be needed for the SpSendMsg_$NCS
and SpReadQ_$NCS calls depending on how the buffer parameter is def
ined. Otherwise each parameter will be initialized and set in the same
way as an ordinary application adaptor. For instance, Figure 1-4 shows
an example of what a call to SpStopProcess_$NCS would look like.



*** Object: code3


Figure 1-4

Creating a foreign host connection, using the design described above,
does present a few limitations. First of all, the HP Sockets system
administration capabilities can not be supported by the foreign host.
This means that the foreign machine will not be able to start and
shutdown the HP Sockets domain. Secondly, since the foreign application
adaptor is not actually running in the HP Sockets domain, the foreign
adaptor cannot be started or stopped by SpStartProcess and
SpStopProcess. Likewise, the foreign application adaptor will not be
able to start the gateway server. Another limitation is that with the
current design, only one application adaptor can be communicating
through the gateway server at a time. Once a SpInit_$NCS call is made,
every call after that point will communicate with HP Sockets under the
logical process name passed in with the initial SpInit_$NCS call.
Although this design does present the above limitations, most systems
would not find them to be a problem. The proposed foreign host
connection using NCS does provide a good functioning gateway for a
foreign application to communicate with the HP Sockets domain.

4.0     Interface to HP Sockets Access Routines

HP provides code for a simple implementation of a connection between a
foreign host and the HP Sockets domain using NCS. Table 1-1 specifies
the level of support the sample code offers for each of the access
routines in HP Sockets.



*** Object: cklist


Table 1-1

A.0     Appendix A: Background

This section will provide the reader with information about the Network
Computing System and HP Sockets.

A.1     Network Computing System (NCS)

The Network Computing System (NCS) is a set of software tools which
allows a developer to build distributed applications across a network
of heterogeneous computers. The system uses a client/server model along
with a remote procedure call(RPC) mechanism as the basis for
development.

The flow of a remote procedure call from a client to the server can be
seen in Figure 1-5. The RPC paradigm hides the remote aspects of a call
from the client so that ordinary calling conventions are used as if the
remote procedure was actually local to the client. The client stub acts
as the remote procedure but in reality it actually marshals the data
and uses the RPC Runtime Library to call the server. The server just
waits around until it receives a request from a client. When a request
comes in, the server stub unmarshals the data (performing any data type
conversions that are necessary) and calls the appropriate procedure.
After the procedure is complete, the server sends back the results of
the operation to the client. This design allows developers a straight
forward and easy way of implementing distributed applications that need
a synchronized request - response behavior.

A major component of NCS is the Network Interface Definition Language
(NIDL) which allows the application developers to define, in a high-
level language, the interface between the client and the server. This
description mainly defines the remote procedures and the type of each
parameter.

The NIDL compiler takes the interface definition and produces C source
code for the client and server stubs. These stubs are then linked into
the client and server so that they can perform data conversions,
assemble and disassemble packets, and interact with the RPC Runtime
Library.

The RPC Runtime Library is the backbone of NCS. It contains routines
which enable local programs to execute procedures on remote systems.
Most applications do not use many RPC Runtime Library calls directly
but rather indirectly through the client and server stubs.

The last major component of NCS is the Local and Global Location
Brokers. These daemons provide NCS applications the ability to be
portable, transparent and protected from network reconfiguration.
Applications use the NCS Location Brokers to locate suitable servers
dynamically at runtime so that applications do not have to hard code
the location of a particular server.

The Local Location Broker (LLB) is a daemon that maintains a database
of information about the different types of servers located on the
local host. The LLB provides access to its database and supports the
RPC forwarding mechanism. Clients can send a remote procedure call
directly to the forwarding port on the desired host and the LLB will
automatically forward the call to the appropriate server on the host.
This eliminates the need for a client to know the specific port that a
server uses and therefore allows the server to obtain a port at
runtime.

The Global Location Broker (GLB) is a daemon that maintains a database
of information about servers throughout the network. Clients typically
issue lookup requests to the GLB when they do not know exactly were a
server is running in the network. This allows clients to dynamically
find a server which could be moved around the network for various
reasons.

The Location Broker concept is the key to the flexibility and
transparency of NCS. Through the use of location brokers, the resulting
client applications are much more portable than with traditional RPC
mechanisms.



*** Object: process


Figure 1-5



A.2     HP Software Integration Sockets

HP Software Integration Sockets (HP Sockets) is a software tool which
provides the ability to integrate new or existing applications in a
network of heterogeneous and homogeneous computers. Flexible data
transfer, data transformation, data manipulation and process control
capabilities provide an environment in which integration can easily be
accomplished between many different types of applications.

The system integrator or developer defines an integrated system in HP
Sockets through a set of configuration files. These configuration files
are created with any ordinary editor (such as vi). Information defined
in these files are used by HP Sockets to provide location transparency
for applications as well as manipulate the data into the correct format
expected by the receiving applications. By defining the configuration
data in a series of files, the user can easily change, update, and
maintain this information in one central location without having to
touch the actual application adaptors.

The HP Sockets Manager (smain) allows the user to validate the
configuration files, start up and shut down the whole integrated
system, and perform other system management related functions. Once a
configured system is started up, via smain, there are a number of
runtime modules that are started up which handle the actual data
manipulation and transportation of data. HP Sockets creates and
compiles these modules from the information that was supplied by the
configuration files. Performance is dramatically increased for data
translation and manipulation since these modules are actually compiled
instead of interpreted.

Applications send and receive messages, data, and files through a
series of 12 access routines. An application adaptor is the user-
written process which is made up of these calls and serves as a bridge
between the application and HP Sockets . The adaptor accesses the
application data and then sends and receives data using the two main
access routines, SpSendMsg and SpReadQ. The data is transparently
manipulated by HP Sockets into the format expected by the receiving
application(s). Table 1-2 lists the 12 access routines along with a
short description of what each one does.

Once the adaptors are written and the configuration files developed and
validated by HP Sockets, the developer can use the Command Processor to
simulate a process for testing and debugging. The Command Processor is
accessed from the HP Sockets Manager (smain).



*** Object: fsis






B.0     Appendix B: Advanced Topics

This section describes possible solutions for functions that are not
supported by the sample code.

B.1  Problem: Since NCS does not support file transfer capability,
there is no way for the foreign application adaptor to send or receive
a file using NCS.

     Discussion: Separate solutions must be considered for sending a
file to the HP Sockets domain versus receiving a file from the HP
Sockets domain. The following solution assumes that the foreign host
supports the File Transfer Protocol (FTP) from ARPA services.

     Possible solution: (Sending a file to the HP Sockets domain) The
SpSendFile_$NCS manager routine on the gateway server could set up an
FTP connection with the foreign host and upload the file. If the file
transfer was successful, the actual SpSendFile routine could then be
called to let HP Sockets finish transferring the file from the gateway
server to the destination process.

     Possible solution:(Receiving a file from the HP Sockets domain) A
file that is sent to the foreign application will be actually sent to
the gateway server. Once the foreign adaptor finds out that a file has
been sent to the gateway server, either with a file notification or a
message from the sending application, the foreign application adaptor
could set up an FTP connection and download the file from the server.


B.2  Problem: With the current design, there is no way to support file
and message notification to the foreign application. Notification is
enabled and disabled by setting and unsetting the SpControl functions
SpSET_MSG_NOTIFY and SpSET_F ILE_NOTIFY.

     Discussion: Since the gateway server is configured in the HP
Sockets domain as the foreign application, the file or message
notification will actually signal the gateway server. However, the
foreign application adaptor is the actual process that needs to be
notified. In order to support file and message notification, there
needs to be a way to send a message from the gateway server to the
foreign host. This is impossible in the current design because the
foreign application adaptor (NCS client) can make remote procedure
calls to the gateway server (NCS server) but the gateway server cannot
issue remote procedure calls to the foreign application adaptor.

     Possible solution: The easiest way to solve this problem is to
develop an NCS server on the foreign host machine. This new server
could provide two remote procedures which would notify the foreign
application adaptor that a message or file was waiting for it on the
gateway server. Exactly how this server would notify the foreign
adaptor depends on the interprocess communication capabilities of the
foreign host machine. Using this implementation, the gateway server
would call the correct remote procedure on the foreign host server
whenever it received a signal that a message or file had arrived. The
new foreign host server would notify the foreign adaptor, in what ever
way that it could, that a message or file has been sent to it and is
waiting on the gateway server.


B.3  Problem: If the buffer parameter for the SpSendMsg_$NCS call is
declared in NIDL as an array of byte, NCS will not perform any
necessary data type conversions.

     Discussion: By specifying the buffer parameter as an array of
byte, the application adaptor can send any number of different data
types with the same procedure . This is the closest mapping to the
behavior of the actual HP Sockets SpSendMsg routine. However, NCS
guarantees that it will not perform any conversions on parameters which
are declared as byte. If there happens to be machine differences in
data type representations between the foreign host and the gateway
server, the data could be misinterpreted. The developer can solve this
problem by creating code in the SpSendMsg_$NCS routine which would
handle the data conversion before the actual HP Sockets call is made.
This would allow the gateway server to handle conversions for any
foreign host which has the same data representation. No matter how the
buffer parameter is declared in the NIDL specification, if HP Sockets
needs to perform any data conversion, realignment, or manipulation,
before it gets to the destination process, the data type needs to be
defined in the Data Definition file.


     Possible solution: The buffer parameter could be specified as the
exact data type that needs to be sent. By specifying the exact type,
NCS will know how and when to perform any data conversions that might
be necessary. If the data type is specified in the NIDL interface
specification, the server will also know what data type is being sent.
If some sort of data conversion occurs, the value of IList [BUF_LEN]
set by the foreign application adaptor might be incorrect. Since the
server will also know what data type is being passed, the server
routine can reset IList[BUF_LEN] to the correct size of the buffer on
the gateway server. One downside to this implementation is that only
one data type can be sent using this procedure. If more than one type
needs to be sent then the developer would need to implement multiple
procedures, one for each type of data (i.e. SpSendMsg1_$NC S,
SpSendMsg2_$NCS, etc.). This is not the most optimal solution since it
adds complexity, creates adaptor code that is less like traditional HP
Sockets adaptor code, and adds quite a bit of repetitious work.

A better solution to this problem is to declare the buffer parameter in
NIDL as a union switch. This would allow the developer to specify a
number of different types that the buffer could represent during
runtime. This would provide the adaptor the capability to send multiple
types of data with the same procedure (exactly what HP Sockets
provides). Since NCS knows the exact data type, it could perform any
data conversions that might be necessary. In addition, the gateway
server will be able to use the discriminator so that it will know which
data type is being sent. The server can then reset the IList[BUF_LEN]
parameter in case the size changed during an NCS data type conversion.

B.4  Problem: If the buffer parameter for the SpReadQ_$NCS call is
declared in NIDL as an array of byte then NCS will not perform any
necessary data type conversions.

     Discussion: The application adaptor can receive any number of
different data types with the same procedure by specifying the buffer
parameter as an array of byte. This is the closest mapping to the look
and feel of the actual HP Sockets Sp ReadQ routine. However, if there
happens to be machine differences in data type representations between
the foreign host and the gateway server, the data could be
misinterpreted unless proper precautions are taken when interpreting
the data within the buffer. The developer could create code in the
SpReadQ_$NCS routine which would handle the data conversion before the
actual call to HP Sockets is made. This would allow the gateway server
to handle any foreign client which has the same data representation.

No matter how the buffer parameter is declared in the nidl
specification, if hp sockets needs to perform any data conversion,
realignment, or manipulation, the data type needs to be defined in the
data definition file.

     Possible solution: One solution is to define the buffer parameter
as the exact data type that needs to be read. By specifying the exact
type, NCS will know how and when to perform any data conversions. If
the data representation on the server is different than the foreign
adaptor, the value of IList[BUF_LEN] set by the foreign adaptor might
be incorrect. Since the server will know the exact type being read, the
server routine can reset IList[BUF_LEN] to the correct size of the
buffer. This will prevent any unexpected results that might of occurred
if ILi st[BUF_LEN] was set greater than the actual size of the buffer.
A downside to this implementation is that only one data type can be
read using this procedure. I f more than one data type needs to be
read, the developer would need to implement multiple remote procedures,
one for each type of data (i.e. SpReadQ1_$NCS, SpR eadQ2_$NCS, ...).
This is not the most optimal solution for the same reasons that were
discussed above for SpSendMsg. In addition, you may not know exactly
what you have read into the buffer until you test to see what the tag
value is.

Another solution to this problem is to declare the buffer parameter in
NIDL as a union switch. This would allow the developer to specify a
number of different types that the buffer could represent during
runtime. This would also provide the adaptor the capability to read
multiple types of data with the same procedure (exactly what HP Sockets
provides). Since NCS would know what type is being passed back to the
client it could perform any data conversion that is necessary . One
catch here is that the gateway server will need to call the actual
SpReadQ routine with a buffer defined large enough for the biggest
type. The server will have to set up some sort of discriminator scheme
with the tag values so that the gateway server knows what type has just
been read. This will allow the gateway server to set the return buffer
parameter and the discriminator so that NCS knows what type is being
passed back to the foreign host. One thing to keep in mind is that the
OList [SpBUF_LEN] variable could be wrong if a data conversion took
place by NCS as the message was transmitted to the foreign adaptor. The
developer should consider the possibility of alignment problems when
performing the actual SpReadQ call. Refer to the HP Sockets Software
Integration Programmer's Manual for more information on this problem.


B.5  Problem: The data on the foreign host might need to be manipulated
before it is sent over to the gateway server.

     Discussion: In some situations, data may need to be manipulated on
the foreign host before it is sent over to the gateway server. One
example is when the internal representation of the data is declared in
a way that prevents NCS from producing marshalling and unmarshalling
code (i.e. trees, linked lists and structures with embedded pointers).

     Possible Solution: The developer can use the NIDL transmit_as
attribute to declare a transmitted type for the buffer parameter. This
attribute associates a transmitted type that stubs pass over the
network with a presented type that clients and servers manipulate. The
developer then provides routines that perform conversions between the
presented and transmitted types. The presented type is converted into
the transmitted type for passage over the network. The transmitted type
is then converted back to the presented type before the server receives
it. However, this feature does not provide the full fledged data
manipulation capability which is supported in HP Sockets.


1.0  Glossary

Access Routines  - The function calls that make up the HP Sockets
access routine library.

Application Adaptor - A user-written program that acts as a bridge
between an application and HP Sockets.

Application Program - A purchased or user-written software product that
performs specific tasks to achieve a well-defined goal.

Binding - The act of designating an object and a server for that object
when mak ing an RPC. Binding in RPC systems is analogous to linking in
conventional procedure calls: it determines the actual code executed
when a call is made. The binding for an RPC is encapsulated in a handle
that is created by the client making the RPC.

Broker - An independent intermediary between clients and servers on a
network. The Location Broker is a broker.

Client - A process that makes RPCs. See also server.

Client Stub - A file generated by the NIDL Compiler that contains
procedures called through the client switch. The client stub marshals
RPC parameters into RPC requests and unmarshals the results when the
RPC returns.

Client Switch - A file generated by the NIDL Compiler that contains
procedures named for the operations specified in the network interface.
RPCs in the client are linked to the procedures in the client switch at
compile time. The client switch procedures will then call the
appropriate client stub procedures through the client EPV

Command Processor - A module accessed through the HP Sockets Manager
that lets you interactively test the messaging and file transfer to any
process or node within the HP Sockets domain.

Daemon - A program designed to run continually as a background process.
Most servers are daemons.

Data Manipulation - Manipulation of data into a format acceptable to a
given process.

Data Transformation - Transformation of data into a format acceptable
to a specified host computer. Examples are ASCII to EBCDIC, 16-bit
integer to 32-bit integer , proper byte-ordering.

Entry Point Vector (EPV) - A record of pointers to the operations in an
interface.

Forward - To dispatch an RPC request to a server that exports the
requested interface. The Local Location Broker forwards RPC requests
that are sent to the LLB forwarding port on a server host.

Forwarding Port - A port number defined in each address family on which
the LLB forwarding agent listens. RPC requests resulting from RPCs made
with unbound or bound-to-host handles are sent to the forwarding agent.

Global Location Broker (GLB) - A database of servers available to a
network.

Handle - A temporary local identifier for an object. A handle
represents for a client process the object and the location of a server
that exports one or more interfaces to the object. A handle always
represents a single object, but it may represent different server
locations at different times, or it may not represent a server location
at all. See also binding.

Host - A processor attached to a network.

HP Sockets Domain - The collection of computers that are configured in
an HP Sockets configuration to work together using the HP Sockets
product. Each computer in the domain is called a node.

HP Sockets Manager - The portion of the HP Sockets software that lets
you administer the HP Sockets domain.


Local Location Broker - A database of objects and servers on a single
host. Each LLB is implemented by a Local Location Broker Daemon (llbd),
which also provides a forwarding agent for servers on the local host.

Manager - A set of functions that implements the operations in an
interface for a particular server.

Marshal - To construct an RPC request from procedure call parameters.
In NCS, the stubs perform marshaling. See also unmarshal.

Message Queue - An HP Sockets queue containing all the incoming
messages for a process. There is one incoming message queue for each
process using HP Sockets. Messages can be sent data by other processes
in the HP Sockets domain.

Network Interface Definition Language (NIDL) - A declarative language
for defining network interfaces. NIDL is part of the Network Computing
Architecture. NIDL has two syntaxes, one resembling C and one
resembling Pascal. The NCS/NIDL product from Hewlett-Packard includes
the software needed to build distributed applications that run over
NCS.

NIDL Compiler - A program that generates from an interface definition
written in NIDL the stub and header files to implement a network
interface. The NIDL Compiler is part of the Network Computing System
and is included in the NCS/NIDL product from Hewlett-Packard.

Open Array - An array whose size is not fixed at compile time. See also
fixed array.

Register - To make something known to NCS. For example, servers
register the objects they manage and the interfaces they export with
the RPC runtime and the Location Broker.

Remote Procedure Call - An invocation of a remote operation. You can
make remote procedure calls between processes on different hosts or on
the same host.

RPC - See remote procedure call.


RPC Handle - See handle.

RPC Runtime - A set of calls that NCS provides to implement and support
its remote procedure call mechanism.

Server - A process that exports one or more network interfaces for one
or more objects. A program that provides procedures that can be called
remotely. See also client.

Server Stub - A file generated by the NIDL Compiler that contains
procedures called by the RPC runtime in response to an incoming RPC
request. The server stub unmarshals RPC parameters and calls the
appropriate manager function through the manager EPV. When the manager
function returns, the server stub marshals the parameters into an RPC
response returned through the server EPV to the runtime.

Socket - A destination for messages on a network. Sockets are labeled
with socket addresses.

Stub - A NCS program module that transfers remote procedure calls and
responses between a client and a server. Stubs perform marshalling,
unmarshalling, and data format conversion. Both clients and servers
have stubs. The NIDL Compiler generates client and server stub code
from a network interface definition.

Switch - See client switch.

Tag Field - A user-defined integer associated with message transfer
requests. Tag field values may be only positive 32-bit signed integers
(not including zero). Use it for user-defined interprocess
communication. For example, a process can uniquely identify data
received from another process. Or, you can prioritize the order in
which messages are removed from the incoming message queue.

Transmittable Types - The data types directly supported in NIDL without
use of the transmit_as attribute. Transmittable types have an invariant
interpretation on all systems.


Unmarshal - To recover procedure call parameters from an RPC request.
In NCS, the stubs perform unmarshalling. See also marshal.

Universal Unique Identifier (UUID) - An identifier used by NCS to
identify interfaces, objects, and types. The defining property of a
UUID is its uniqueness; a UUID encodes both the time and the place of
its creation. The algorithms used to generate UUIDs are designed never
to produce the same UUID twice. A UUID can be generated anywhere at
anytime without appealing to a centralized administrator, yet is
guaranteed to be unique .

Unregister - To withdraw a registration. See also register.

Virtual Adaptor - A server process which has a virtual connection to a
client app lication, and that provides HP Socket functionality on
behalf of the client.

2.0     References

HP Software Integration Sockets, Technical Overview (5951-6979) HP
Software Integration Sockets, Programmers Manual (92568-90001) HP
Software Integration Sockets, System Administrator's Manual (92568-
90002) HP Software Integration Sockets, Self-Paced Tutorial (92568-
90003) Network Computing System Reference Manual, 010200-A00 Managing
NCS Software, 011895-A01, October 1989